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REMARKS 

Amendments to claims 1,19, and 37 are for the purpose of clarifying what Applicants 
regard as the invention. Amendment to claim 13 is to insert a punctuation mark. No new matter 
has been added. 

I. CLAIM REJECTIONS UNDER 35 U.S.C. § 102 

Claims 1-50 stand rejected under 35 U.S.C. § 102(e) as being anticipated by U.S. Patent 
No. 6,385,724 (Beckman). Applicants respectfully note that in order to sustain a rejection under 
§102, each element in the rejected claim must be found, either expressly or inherently, in the 
cited reference. 

Claims 1 and 19 

Claim 1 has been amended to recite implementing a data object that indicates, before a 
link is established between the first and second network nodes, whether the domain permits the 
link between the first and second network nodes without verification of user credentials 
(emphasis added). Claim 19 has been amended to recite a similar limitation. Applicants submit 
that the claim amendments has overcome the § 102 rejection under Beckman because the cited 
passages (column 11, lines 23-67, and column 12, lines 1-19) do not disclose or suggest the 
above limitation. In particular, the cited passages disclose: 

A token is kept as part of a process's information to indicate the user initiating the 
process. By default, calls originating from the process are identified by the 
operating system as associated with the process's token. Alternatively, an identity 
can be kept as part of a thread's information (e.g., to facilitate impersonation of a 
remote user). For example, the thread on which the client object 206 (FIG. 3) is 
executing may be associated with a token. If so, calls on the thread are identified 
by the operating system as associated with the thread's token. 

A network connection between two machines (e.g., over a LAN or the Internet) 
can provide a certain degree of confidence about identities reported over the 
connection. Whenever a caller's identity is provided over a network connection, 
the degree of certainty about the caller's identity is represented as a particular 
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authentication level. When the authentication service creates a token, the 
authentication level information is not placed into the token, but the 
authentication level used for a particular call is available from COM APIs. 

Authentication levels supported by Windows NT include none, connect level 
authentication, call level authentication, packet level authentication, packet 
integrity level authentication and encrypted packet authentication. A low 
authentication level (e.g., none), indicates no steps have been taken to 
authenticate the user's identity. At the authentication level "none," the user's 
identity is not available to the server. A higher authentication level (e.g., per- 
packet), indicates that some steps (i.e., each packet has been authenticated) have 
been taken to authenticate the user's identity. For example, the connect level 
indicates the user's identity was authenticated when the connection is first made 
(e.g., using a challenge/response scheme). The following table illustrates various 
authentication levels defined for Windows NT: 



TABLE 1 
Name 

RPC_C_AUTHN_LEVEL_NONE 
RPC C AUTHN LEVEL CONNECT 



RPC C AUTHN LEVEL CALL 



RPC C AUTHN LEVEL PKT 



RPC_C_AUTHN_LEVEL_PKT_ 
INTEGRITY 



RPC_C_AUTHN_LEVEL_PKT 
PRIVACY 



(Emphasis added) 



Description 
No authentication. 
Authentication occurs when a 
connection is made to the 
server. Connectionless proto- 
cols do not use this, 
see _PKT, below. 
The authentication occurs 
when a RPC call is accepted 
by the server. Connectionless 
protocols do not use this, 
this, see _PKT below. 
Authenticates the data on a 
per-packet basis, all data is 
authenticated. 
This authenticates that the 
data has come from the client, 
and it checks that the data 
has not been modified. 
In addition to the checks 
made by the other authenti- 
cation techniques, this 
encrypts the packet. 
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According to column 1 1, lines 44-49 of Beckman, the authentication level "None" is used to 
indicate that no steps have been taken to authenticate a user's identity. As such, the 
authentication level "None" is used to describe a type of authentication that has already been 
performed for an established link, and is not a data object that is used to indicate, before a link is 
established, whether a link can be established between two nodes. For at least the foregoing 
reason, claims 1 and 19, and their respective dependent claims, are believed allowable over 
Beckman. 

Claim 37 

Claim 37 recites a data object associated with the domain, the data object indicating, 
before a link is established between the first network node and the second network node, whether 
a link can be established between the first network node and the second network node without 
verification of user credentials (emphasis added). Beckman does not disclose or suggest such 
limitation. Rather, as discussed previously, Beckman discloses an authentication level "None" 
which indicates that no steps have been taken to authenticate a user's identity. As such, the 
authentication level "None" is used to describe a type of authentication that has been performed 
for an established link, and is not a data object that is used to indicate, before a link is 
established, whether a link can be established between twomodes. For at least the foregoing 
reason, claim 37 and its dependent claims are believed allowable over Beckman. 
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CONCLUSION 

Based on the foregoing, all remaining claims are in condition for allowance, which is 
respectfully requested. If the Examiner has any questions or comments regarding this 
amendment, the Examiner is respectfully requested to contact the undersigned at the number 
listed below. 

The Commissioner is authorized to charge any fees due in connection with the filing of 
this document to Bingham McCutchen's Deposit Account No. 50-2518, referencing billing 
number 7010852004. The Commissioner is authorized to credit any overpayment or to charge 
any underpayment to Bingham McCutchen's Deposit Account No. 50-2518 , referencing billing 
number 7010852004. 

Respectfully submitted, 
Bingham McCutchen LLP 



Dated: August 19, 2005 By: C^^>^ 



Gerald Chan 
Registration No. 51,541 



BINGHAM McCUTCHEN LLP 
Three Embarcadero Center, Suite 1800 
San Francisco, CA 941 1 1-4067 
Telephone: (650) 849-4960 
Telefax: (650) 849-4800 
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